Most Internet applications either suffer or have suffered from problems relating to Internet Protocol (IP) address realm transitions. Such problems are particularly prevalent since the format of IP addresses is currently changing with the introduction of IP version 6 (IPv6) address realm to replace the IP version 4 (IPv4) address realm (as the number of addresses available under the IPv4 realm is no longer sufficient to meet demand). Examples of these problems include the inability to place servers behind Network Address Translators (NATs), difficulty in communicating from the IPv4 Internet to the IPv6 Internet and vice versa, limitations in multimedia applications that do not employ global addresses, and so on. A Name Address Translator, as an example, translates between an internal IP address of a device and the global IP address of the device—where the internal IP address is allotted to a device by local network, which may not want the internal address to be sent outside the network's firewall.
A number of solutions have been devised to deal with these problems. For instance, many applications and protocols have built-in “NAT traversal” mechanisms and a plethora of IPv4-to-IPv6 transition mechanisms exists. These solutions have, however, created a number of problems of their own.
One problem is that the inherent ambiguity of local address space leads to trial-and-error approach to finding a working path to a peer. A peer found through a server might be in the local network, or might be in a different local address space somewhere else. Moreover, the security of this approach relies entirely on probing and is susceptible to attackers on the path. For instance, an attacker in a local network would be capable of hijacking communications intended to someone else, even if the SIP server exchange that delivered the peer's address were performed securely.
Another problem is that configuration is needed in many of the solutions, and hence it becomes impossible for new devices to work “out of the box” in an automatic fashion. For instance, the Microsoft® Teredo IPv4-IPv6 transition service requires the configuration of the server's address, and typically requires the configuration of a shared key between hosts and servers.
In a communications network, a particular device may be identified by two or more addresses. The addresses may belong to different address realms from one another, or may belong to the same realm. In the communication network shown in FIG. 1, a host 1 in a first network (network 1) is communicating with a peer host 2 in another network (network 2) over, for example, an IP backbone 3. If host 1 has two different IP addresses, such as an IPv4 address and an IPv6 address, packets sent from host 2 to host 1 may identify host 1 as the destination by either the IPv4 address of host 1 or the IPv6 address of host 1. The choice of which address to use may for example depend on network availability or on other requirements—for example, some Internet technology is fundamentally limited to using IPv6 addresses. Thus, if host 2 is directing packets to the IPv6 address of host 1, host 1 might wish at some stage to instruct host 2 to switch to use the IPv4 address for host 1, or vice versa.
Assume that packets are being sent from a device in network 2, for example device 21, to host 1 of network 1, for example, in response to a request made by device in network 1. If the original request specified that the IPv6 address of host 1 should be used, the packets arriving at host 2 from device 21 will specify, as their destination address, the IPv6 address of host 1. If host 1 wishes to switch to using its IPv4 addresses, host 1 would send a re-direction message to host 2; the re-direction message would contain the IPv4 address for host 1, and would instruct host 2 to re-direct packets destined for host 1 to this IPv4 address rather than to the IPv6 destination address specified in the packet. Host 2 would then re-direct packets intended for host 1 to the IPv4 address of host 1 rather than to the IPv6 address.
One problem is that host 2 needs to be able to authenticate a received message that instructs it to re-direct packets to a new address. A malicious host, shown as host 4 in FIG. 1, could wish to intercept the packets passing from host 2 to host 1. The malicious host might therefore send a message to host 2 that contains an IP address for host 4, or for a device controlled by host 4, and instruct host 2 to re-direct packets destined to host 1 to this new address rather than to the IPv6 address for host 1 specified in the packets. If host 2 were to obey this instruction, host 2 would re-direct packets to the malicious host 4 rather than to the intended host 1. It is therefore important that host 2 should be able to distinguish between a genuine re-direction message sent by host 1 and a malicious re-direction message sent by host 4.
An IPv6 address typically has the form of a prefix and a suffix. The prefix of the address is a “routing prefix” and is allotted to, for example, a host such as the host 1 in FIG. 1. The suffix is an “interface identifier”, and identifies a particular device. Whenever a device in the network controlled by the host 1, such as device 11 in FIG. 1, wishes to connect to the Internet, an IPv6 address is generated for that device by choosing a suffix and combining the suffix with the routing prefix allotted to host 1. It is then necessary to check that the generated IPv6 address is not already in use by another device in the network, ie to check that the particular interface identifier suffix chosen for device 11 is not already in use by another device in the network 1. This done by broadcasting a message that includes the IPv6 address generated for device 11 and asking other devices in the network, such as the devices 12,13 in FIG. 1, to indicate if they are already using the address. This process is, however, also vulnerable to attack by a malicious party. For example, if malicious host 4 were to read the broadcast message including the IPv6 address generated for device 11 and respond by claiming that the particular IPv6 address chosen for device 11 was already in use, the device 11 would not be allotted that IPv6 address. It would be necessary to generate another IPv6 address for device 11, and to broadcast a message including that address to check whether it was in use. If the malicious host 4 were to respond to every such broadcast message by claiming that the IPv6 address included in the message was already in use, the malicious host 4 would be able to prevent an IPv6 address being allotted to device 11.